home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930014.txt < prev    next >
Internet Message Format  |  1994-06-04  |  10KB
  1. Date: Thu, 14 Jan 93 04:30:12 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #14
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Thu, 14 Jan 93       Volume 93 : Issue   14
  11.  
  12. Today's Topics:
  13.                           AX.25 under Linux
  14.                                   BM
  15.                 KISS and concatenated TCP ACK packets
  16.                      PNEWS.COM: NOS news posting
  17.                    Routing for Australia. (3 msgs)
  18.  
  19. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  20. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the TCP-Group Digest are available
  24. (by FTP only) from UCSD.Edu in directory "mailarchives".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Wed, 13 Jan 1993 12:35:08 -0800 (PST)
  32. From: Bruce Perens <bruce@pixar.com>
  33. Subject: AX.25 under Linux
  34. To: tcp-group@ucsd.edu
  35.  
  36. I tracked down the person who had done an AX.25 driver in the Linux
  37. kernel. He currently has the driver working for TCP/IP only, there is no
  38. direct access to AX.25 without using IP. I haven't gotten a look at his
  39. code yet, hopefully I will soon.
  40.  
  41. I've been thinking about adding an AX.25 address family and protocols to
  42. the Linux kernel. I'd copy the interface of Phil Karn's AF_AX25
  43. implementation. This might make it possible to break existing KA9Q
  44. clients and servers out into individual processes under Linux. 
  45.  
  46.      Bruce Perens
  47.  
  48. ------------------------------
  49.  
  50. Date: Wed, 13 Jan 93 09:41:58 EST
  51. From: crompton@NADC.NAVY.MIL (D. Crompton)
  52. Subject: BM
  53. To: tcp-group@ucsd.edu
  54.  
  55. First of all NN2Z if you are listening - I am either blind or looking
  56. in the wrong place but I do not see a new bm in UCSD's incoming??
  57.  
  58. I asked this quite awhile back - How do you view mail directories
  59. below /spool/mail in BM.  'n xxx/yyy' does not work.
  60.  
  61. I usually use BM to view my mail but I guess I could make an area
  62. to the subdir and use the NOS BBS also. 
  63.  
  64. Doug
  65.  
  66. ------------------------------
  67.  
  68. Date: Wed, 13 Jan 93 15:37:08 -0500
  69. From: grebus@isis1.bxb.dec.com (Gary Grebus)
  70. Subject: KISS and concatenated TCP ACK packets
  71. To: MIKEBW@ids.net, tcp-group@ucsd.edu
  72.  
  73. >I would STRONGLY discourage anyone from implementing the ACKPRIOR scheme.
  74. >While it looks logical on paper, listening to a channel where it is being
  75. >run will immediately indicate a problem: there is no space for other users
  76. >to get in when two stations are sending data to each other using ACKPRIOR.
  77. >MFJ TNCs default to ACKPRIOR enabled, and they are the bane of packet.
  78.  
  79. I've never actually seen an exact description of the AX.25 "Priority ACK".
  80. It seems like it should require a node sending data (as opposed
  81. to just an ACK) to contend for the channel normally?  And it doesn't
  82. help with links that run using UI-frames.
  83.  
  84. >The proper solution to sending three TCP ACKs when only the last is
  85. >necessary is to run a NOS timer of about 5 seconds before sending an ACK.
  86. >This is how the netrom code implements ACKs.  (At least, this is the way
  87. >it does now since I fixed a bug in the routine that does it.)  In other
  88. >words, have an incoming TCP frame start a timer (if none is already in
  89. >progress) that will cause an ACK to be sent.  If more TCP frames arrive
  90. >between the starting and expiring of the timer, the ACK will be sent for
  91. >them also, so that the ACK is current as of the expiration of the timer.
  92.  
  93. That works assuming that the remote end is able to send new data.  The
  94. case I've seen is that the local end is unable to successfully send an
  95. ACK, and the remote is retransmitting.  Thus the TNC queues multiple
  96. ACKs for the same data.  It seems like the round-trip-time calculations
  97. should eventually adjust for this, but its not clear to me if that
  98. actually happens.  This situation also implies some sort of fairness problem
  99. with channel access...the remote is able to access the channel more
  100. often (to send data) than the local (to ACK it).
  101.  
  102.  /gary
  103.  K8LT
  104.  
  105. ------------------------------
  106.  
  107. Date: Thu, 14 Jan 1993 00:48:50 +0200
  108. From: Costas Krallis SV1XV <kkrallis@leon.nrcps.ariadne-t.gr>
  109. Subject: PNEWS.COM: NOS news posting
  110. To: tcp-group@ucsd.edu
  111.  
  112. I created this program today, based mainly on EI9GL's
  113. sources for "bmh". It seems to work OK with WG7J NOS
  114. and after some more testing, clean-up etc I'll upload
  115. it to ucsd.edu, most likely next Sunday. 
  116. The program is 27k and compiles with Turbo-C 2.0
  117.  
  118. 73 Costas SV1XV
  119.  
  120.  
  121.  
  122. ------------------------------------------------------------------
  123. |   Dr. K. Krallis  SV1XV *   Epsilon Software S.A.
  124. |  ------
  125. |  Internet:  kkrallis@leon.nrcps.ariadne-t.gr
  126. |  Packet radio: SV1XV @ SV1IW.ATH.GRC.EU
  127. |  AMPRnet:   sv1xv@sv1xv.ampr.org         [44.154.1.11]
  128. |  Snail Mail:  P.O.BOX 3066, GR-10210 Athens, GREECE
  129. ------------------------------------------------------------------
  130.  
  131.  
  132.  I'd like to use NOS to introduce the local 
  133. packet group to it, but I'm open to suggestions if somthing else is
  134. more appropriate.
  135.  
  136. Thanks and Cheers
  137. James Dean
  138. jdean@drao.nrc.ca
  139. VE7JWD @ VE7EHS
  140.  
  141. ------------------------------
  142.  
  143. Date: Wed, 13 Jan 93 10:11 CST
  144. From: Jay Maynard                          <S0JM@ADMIN.HSC.UTH.TMC.EDU>
  145. Subject: Routing for Australia.
  146. To: tcp-group@UCSD.EDU
  147.  
  148. > Is it possible to have a router defined to handle a subnet of network
  149. > 44?
  150.  
  151. Not as the Internet routing model is currently defined.
  152.  
  153. The idea is that a network is solely responsible for routing
  154. frames from its Internet gateway to any machine within the
  155. network. Subnetting is used to make routing within a network
  156. easier, but doesn't help at all with routing from outside the
  157. network.
  158.  
  159. > The problem for people outside of the US is that all frames from the Internet
  160. > to Amprnet go via mirrorshades at ucsd.  This means that the 512Kb link
  161. > between Australia and the US is unneccessarily carying frames over and then
  162. > back (via encap).
  163.  
  164. Yep, and there's no way around it so long as you stay within net
  165. 44 short of routing the frames back to Australia over another
  166. link, such as a radio link.
  167.  
  168. > I was wondering if it was possible for us to have all 44.136 frames routed
  169. > to a machine like minnie.  (This is ignoring the problem of how
  170. > do we get the router information setup in the first place. :-( )
  171.  
  172. That problem will defeat any such effort, as the protocols the
  173. Internet uses to determine how to route frames for a given
  174. destination between gateways over the backbone only consider net
  175. numbers when making decisionsl; hence, there can be only one net
  176. 44 gateway to the rest of the Internet.
  177.  
  178. ...Jay, K5ZC
  179.  
  180. ------------------------------
  181.  
  182. Date: Wed, 13 Jan 1993 15:37:33 -0600
  183. From: miltonm@inetnode.austin.ibm.com (Milton Miller)
  184. Subject: Routing for Australia.
  185. To: tcp-group@UCSD.EDU
  186.  
  187. But it might be possible for a regional network to say all of net 44 that
  188. it sees goes to this address, and forget what any other administrative 
  189. domain says.  Then you would get all net 44 traffic that made it to  
  190. the administrative domain boundary (the reverse problem :-)
  191.  
  192. milton
  193. KB5TKF
  194.  
  195. <I don't speak for IBM>
  196.  
  197. ------------------------------
  198.  
  199. Date: Wed, 13 Jan 1993 18:27:19 -0500
  200. From: chk@alias.com (C. Harald Koch)
  201. Subject: Routing for Australia.
  202. To: S0JM@ADMIN.HSC.UTH.TMC.EDU (Jay Maynard)
  203.  
  204. > That problem will defeat any such effort, as the protocols the
  205. > Internet uses to determine how to route frames for a given
  206. > destination between gateways over the backbone only consider net
  207. > numbers when making decisionsl; hence, there can be only one net
  208. > 44 gateway to the rest of the Internet.
  209.  
  210. Your information is a little out of date. The current Internet routing
  211. systems understand both subnets and route aggregation. Basically, the new
  212. algorithms consider a 'network' as a IP-addr/mask pair.
  213.  
  214. Examples of subnets:
  215.  
  216. net 44.136 becomes  44.136.0.0/255.255.0.0
  217. net 192.75.93.[2-6] becomes 192.75.93.0/255.255.255.148
  218.  
  219. An example of route subsumtion:
  220. nets 192.75.20, 192.75.21, 192.75.22, 192.75.23 can be advertised using a
  221. single route entry for  192.75.20.20/255.255.252.0
  222.  
  223. -- 
  224. Main's Law: For every       | C. Harald Koch  Alias Research, Inc. Toronto, ON
  225. action, there is an equal   | chk@alias.com                (work-related mail)
  226. and opposite goverment      | chk@gpu.utcs.utoronto.ca     (permanent address)
  227. program.                    | VE3TLA@VE3OY.#SCON.ON.CA.NA            (AMPRNet)
  228.  
  229. ------------------------------
  230.  
  231. Date: Thu, 14 Jan 93 09:18:29 GMT
  232. From: Alan Cox <iiitac@pyr.swan.ac.uk>
  233. To: tcp-group@ucsd.edu
  234.  
  235. Priority packets are easy with UI frames, you just stuff them earlier
  236. down the sending queue for the kiss device.
  237.  
  238. I've been watching the multiple acks and the rtt doesn't help in many cases
  239. because round trip times seesaw wildly, and worse still the more acks
  240. being mistakenly sent the more acks blocking the channel, the slower
  241. the data arrives, causing more acks 
  242.  
  243. Alan
  244.  
  245. ------------------------------
  246.  
  247. End of TCP-Group Digest V93 #14
  248. ******************************
  249. ******************************
  250.